Atari Mega Archive 1/Atari Mega Archive - Volume 1.iso/lists/gem/l_1199/1036

Internet Message Format | 1994-08-27 | 7.9 KB

Date: Tue, 26 Jul 1994 12:57:15 -0400 (EDT)
From: Timothy Miller <[e-mail]>
Subject: Re: A better objc_edit()
To: [e-mail]
In-Reply-To: <[e-mail]>
Message-Id: <Pine.3.87.9407261215.J7249-0100000@grad>
Mime-Version: 1.0
Precedence: bulk

Warwick:

]Tim Miller:
]>Warwick:
]>]Tim:
]>]>Are the icons on the desktop part of a desktop form?  If so, how do
]>]>programs get away with replacing the the background without removing the
]>]>desktop's object tree?
]
]>]It DOES remove the desktop's tree.
]
]>Since it removed the desktop form, why do the icons still show up?
]
]If you mean those pretty icons on the desktop (drives, etc.) - they don't
]show up - they're objects on the Desktop's desktop-window.  If you mean
]iconified windows - they're just windows, and behave as such.
]
]Sorry for the confusion.

What I'm asking is... how does an application put up a backdrop on the
desktop, presumably by replacing the desktop form, and still have the
desktop icons appear which were on a different form?



Everyone:

You're complaining about the size of window libraries?  How about mine?
It's less than 20k!  :)


Hollis:

]Besides, I thought this conference was for discussing standards, and not
]arguing over stupid little piddly crap like this.

Bravo, Bravo!  Let's get down to some useful business.



]> Here's an idea for operating back-ground windows...  put an event
]> rectangle around your window and watch for the mouse to move outside of
]> your window.
]
]This is not necessary, and it is very time-wasting.  Considering, that
]when you move your mouse, you are checking the rectangles under the mouse
]for which object your mouse moves under for the top window.  Remember, when
]the mouse leaves the window, objc_find reports a -1 (for desktop) and you
]can then do other things like move icons on desktop or whatever.  Your
]method is inefficient.  Try re-designing and re-thinking it.  I'm not trying
]to insult you, but, just think about it.  :-)

Somehow, I don't think you quite understood me.  I have no problem with
handling clicks on the desktop.  The point was to simulate WF_BEVENT in
normal TOS.  With normal TOS, if I click on a window, the window gets a
WF_TOPPED message.  Since I want to avoid that, I have to handle mouse
events myself.  On the other hand, I want the events for the TOP window
to be handled automatically (like the slider, close button, etc.).  So,
the solution I proposed was to put an event rectangle around the top
window.  When the mouse is within the top window, events would be handled
normally.  When the mouse it outside of the top window, on the other
hand, events will be given to my program which can then pass messages to
other windows if necessary.

What I need to know is how to find out the owner of a window with normal TOS.


]> When it does, monitor all mouse activity [wind_update(BEG_MCTRL)], and
]> when you get a click, process it.
]
]Monitor *all* mouse activity?  Ouch!  I thought that's what everyone else
]was flaming us about; it's too "busy-waiting"...

It's not busy-waiting at all... event_multi will pass mouse events to my
application when MCTRL is set, otherwise, the OS just sits there.  And
besides, who cares about busy-waiting when you're not multitasking?

]> If it's an action on one of YOUR windows, then select buttons, whatever;
]> top if necessary.  If it's someone else's window, send a message to the
]> application, telling it to top the window.
]
]Simply do this:  A button "press" activates a dialog inside a background
]window.  A button "click" tops the window.  Press meaning hold down the
]mouse button.  Click meaning tapping the mouse button.

You can't make a distinction with normal TOS.  You only get WF_TOPPED
messages.  What I'm trying to do is simulate WF_BEVENT when I don't have
a multitasking OS.

]> 1.  When you find another app's window and find out its handle, how do
]>     you get the application ID of that app so you can send it a message?
]
]>From what I understand, there's no real easy way.  Sure, you can get the
]window handle, but the only way to really get the application ID of the
]owner is to use WF_OWNER.  Another way is to use appl_find("PROGNAME") and
]check if it is installed...  I think that's not possible any other way
]except with WF_OWNER.

There doesn't seem to be WF_OWNER under normal TOS, and getting a
window's handle doesn't give me the application's name, does it?


]> Could someone give me replacement code for form_button?  I'm sure I could
]> do it myself (and in fact will), but I just want to make sure that I'm
]> not missing something.  I need to know what it does in detail.
]
]What type of code are you looking for?  Try using atari.archive.umich.edu
]and checking the programming directory, or use ftp.uni-kl.de to check its
]programming directory.  E-GEM is a very good example of form_button code.
]Once I release XAES's source, you will also see our form_button code which
]is highly optimized.

I just want example code I can use to make sure that mine doesn't miss
something.  I want a form_button replacement that will work on a
background window, using the rectangle list of the window.


]> Oh, and objc_edit code would be nice too.  :)  Although, I don't believe
]> in sending keypresses to anything other than the top window, so
]> replacement objc_edit wouldn't be very useful.  <shrug>
]
]The only real reason you would create your own objc_edit routine is to
]have INSERT/REPLACE, or to have a scrollable text object (like allowing the
]user to enter 40+ characters in a field)

Oh, I don't even need that.  If some exotic key were to be pressed, I
could just pass something DIFFERENT to form_keybd.

For example, when you click the first time on an edit field, it acts
normal, but the second time, it will move the insertion point to where
you clicked by repeatedly sending arrow keys to form_keybd.


]> Are the icons on the desktop part of a desktop form?  If so, how do
]> programs get away with replacing the the background without removing the
]> desktop's object tree?
]
]When you set WF_SCREEN, you are placing a dialog on the desktop.  This
]dialog gets redrawn automatically by GEM, so when you move a window over it,
]it automatically redraws itself.  To FORCE a redraw of the desktop, all you
]have to do is send a form_dial(3, 0, deskx, desky, deskw, deskh, deskx,
]desky, deskw, deskh).  That is documented in MultiTOS documentation too.

You didn't answer my question.


Kevin:

]> I can see what you're saying.  A duplicate screen would be rather memory
]> expensive.  Nevertheless, what I did was still noticably faster... PLUS
]> it kept track of the contents of the window for when I had to redraw a
]> section.
]>
]It may well be a lot faster, but its hideously expensive and inefficient.
]The main window of my first real gem application was a scrolling CLI window,
]and I initially considered doing redraws by maintaining a blittable copy of
]the screen. I soon realised I was just being lazy and did it properly though
]- I now save the objects on the screen (ie characters and their display
]attributes) instead, which has the advantage of taking less memory, of
]not having variable memory requirements for different colour depths, and of
]not being appreciably slower (apparently Ofir thought I was still blitting
]the screen for a while). It also gives me things like scrollback and cut and
]paste for free.

I was writing a terminal program and the other way was WAY too slow.  I
was doing everything I possibly could to squeeze every little bit of
speed out of the computer I possibly could.  Everything I did DID speed
things up, but I never got it fast enough.  It simply could not keep up
with full-tilt 57600 bps while scroolling... and I was doing
jump-scrolling.  GEM just simply is NOT fast enough, so I gave up.  I
haven't found anything that could come close to the speed of ANSITerm
with its optimized character display and hardware scrolling... THAT WILL
keep up with full-tilt 57600 bps on a Falcon.